Productivity software continues to evolve to provide new applications that exchange, process, manage, display, and represent data. However, despite the constant release of new or improved products, consumers often simply desire a product that combines the merits of several existing applications to display or represent data in a way that is unsupported by any of the applications alone. Many Software manufacturers attempt to accommodate customers by periodically offering newer versions or features of their applications, yet no single application can capture the breadth of possible combinations of divergent applications into a single offering.
Data rerepresentation is a special presentation of data maintained by an existing application, which is not ordinarily capable of providing the desired special presentation. Lacking suitably customized applications, customers sometimes attempt to re-program existing applications to accommodate their rerepresentaional needs, but often with only marginal success. Existing solutions generally lack sufficient structural stability. Innumerous functional interdependencies, legacy support considerations, source tree limits, and countless other design and implementational factors place constraints on the amount of change that an application will safely tolerate without risk to runtime stability. Any change may perturb the entire system, which further increases the difficulty of re-programming an existing application to flexibly rerepresent data based on individualized need.
Application programming interfaces (APIs) offer only a partial alternative to re-programming data rerepresentation in an application. APIs facilitate data sharing between applications, which can be customized as a rerepresentation. However, APIs are passive constructs particular to each called application and require specific callback facilities from the receiving application to enable synchronization of the data with the sending application. Moreover, without synchronization, a user is unable to switch back and forth between the data representations of the applications, which can result in inconsistent data interpretation.
Conventional model-view-controller selections attempt to separate data from the user interface of an application to facilitate multiple views of the data. A controller processes user actions through the user interface and updates a model, which maintains the data based on the user actions. All views that depend on the model are also updated. In addition, the controller provides changes directly to the view, which obtains data from the model. To change the view, though, the controller must expressly reprogram the underlying application, which can undermine operational stability and will also necessitate further modification of the application for each change in the view.